You are not logged in.
Hi,
I guess itæs till too early to say which side will "win" in the feude between libav and ffmpeg. As I haven't cared at all, I haven't done anything but keep using ffmpeg. But I currently had to install libav from AUR because ffmpeg just can't handle the Apple HTTP LS streams from Norwegian Broadcaster NRK, while someome said the command I used that should have worked, worked nice for them under ubuntu, whic uses libav. An indeed it does.
Ths broke several players though, Dragon and vlc I hve noticed so far. The reason is that the dependencies (among) other things are not idential.
Now, I won't say Arch should go with the one or the other, but it certainly would be nice if it was possible to have them both in the repos and working alongside each other when it comes to deps and conlicts with other pacjages. (Naturally they couldn't coexist on the same system.) At this point, after so much time has passed, and concidering the number of distros that have switched to libav, NOT recognizing and providing libav as an option seems very muh like taking sides, which I was under the impression from the initial discusion back in '11 that Arch wouldn't do. So if any TU ha the time, and the will, would it be posible to provide both.
I expect minor differences in breakage and functionality to crop up mor and more often, and having bth availible could certainly be a plus.
It's just too bad tht none of the projects spends any time whatsoever improving their documentation, which is often outdated and incorrect. Now, THAT would have been nice...
edit: Is it corect that every package has to be compiled specifically for one or the other? I guess that's that for including them bot, then.
Last edited by naguz (2012-08-02 23:18:48)
Offline
If a dev is interested, he/she will do it. The devs don't really visit the forums (mostly) so this thread is unfortunately quite pointless.
I suggest you investigate a bit more concerning this matter (libav/ffmpeg does not interest me at all, for example) and then post a feature request on the bug tracker/flyspray. It'll get assigned to the right dev and affirmed/rejected based on that. Patches welcome the most likely response, though.
Actually, you should see if there's already a report for that, I believe I've heard about it some time back.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Hi. can you post a short guide to how you got the HLS stream to work? would be cool to test it
Offline
But I currently had to install libav from AUR because ffmpeg just can't handle the Apple HTTP LS streams from Norwegian Broadcaster NRK, while someome said the command I used that should have worked, worked nice for them under ubuntu, whic uses libav.
How can I reproduce this? Please show your command and the complete console output. FFmpeg should be able to do anything libav does and probably more since FFmpeg merges most stuff from libav (which occasionally cherry-picks from FFmpeg).
Now, I won't say Arch should go with the one or the other, but it certainly would be nice if it was possible to have them both in the repos and working alongside each other when it comes to deps and conlicts with other pacjages.
libav-git in AUR seems to be filling this niche just fine. I see no reason for Arch to move libav to community or extra, and the maintenance burden of providing two similar (but different) packages, and getting the dependencies to work with both, would probably be an unreasonable expectation. However, I am not an Arch maintainer, but I can imagine that it is a large undertaking for Ioni to deal with FFmpeg alone.
At this point, after so much time has passed, and concidering the number of distros that have switched to libav.
I only know of two: Debian, and therefore, Ubuntu, and this is because the package maintainer is developer of libav and switched from FFmpeg to libav on his own accord. I don't think following in the footsteps of Debuntu just to follow a perceived status quo is a good idea for Arch.
It's just too bad tht none of the projects spends any time whatsoever improving their documentation...
This is not true. Unfortunately the documentation does need improvements in some areas but there are updates to the documentation almost daily, and if you see something that could be improved you are more than welcome (and encouraged) to submit a patch or at least make a feature request in the bug tracker. Additionally, the FFmpeg wiki has a Community Contributed Documentation section that anyone can contribute to (mostly various usage and compiling guides as of now).
Last edited by DrZaius (2012-08-04 06:03:57)
Offline
How can I reproduce this? Please show your command and the complete console output. FFmpeg should be able to do anything libav does and probably more since FFmpeg merges most stuff from libav (which occasionally cherry-picks from FFmpeg).
Here is the output from ffmpeg (This include the command line, Best:)
[spoiler]
[gert@blad ~]$ ffmpeg -i http://nordond39a-f.akamaihd.net/i/no/open/bf/bf8ca71f099953f35eec1d087cc8fd5bc13ecd0d/bf8ca71f099953f35eec1d087cc8fd5bc13ecd0d_,141,316,563,1266,2250,.mp4.csmil/master.m3u8#t=10,20 -vcodec copy -acodec copy -f mp4 -absf aac_adtstoasc Moby_Dick_part1.mp4
ffmpeg version 0.11.1 Copyright (c) 2000-2012 the FFmpeg developers
built on Jun 9 2012 13:50:13 with gcc 4.7.0 20120505 (prerelease)
configuration: --prefix=/usr --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-libx264 --enable-libvpx --enable-libtheora --enable-libgsm --enable-libspeex --enable-postproc --enable-shared --enable-x11grab --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libschroedinger --enable-libopenjpeg --enable-librtmp --enable-libpulse --enable-libv4l2 --enable-gpl --enable-version3 --enable-runtime-cpudetect --disable-debug --disable-static
libavutil 51. 54.100 / 51. 54.100
libavcodec 54. 23.100 / 54. 23.100
libavformat 54. 6.100 / 54. 6.100
libavdevice 54. 0.100 / 54. 0.100
libavfilter 2. 77.100 / 2. 77.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 15.100 / 0. 15.100
libpostproc 52. 0.100 / 52. 0.100
Input #0, hls,applehttp, from 'http://nordond39a-f.akamaihd.net/i/no/open/bf/bf8ca71f099953f35eec1d087cc8fd5bc13ecd0d/bf8ca71f099953f35eec1d087cc8fd5bc13ecd0d_,141,316,563,1266,2250,.mp4.csmil/master.m3u8#t=10,20':
Duration: 01:31:03.00, start: 0.100667, bitrate: 0 kb/s
Stream #0:0: Video: h264 (Baseline) ([27][0][0][0] / 0x001B), yuv420p, 320x180 [SAR 1:1 DAR 16:9], 25 tbr, 90k tbn, 50 tbc
Metadata:
variant_bitrate : 213000
Stream #0:1: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, mono, s16
Metadata:
variant_bitrate : 213000
Stream #0:2: Video: h264 (Baseline) ([27][0][0][0] / 0x001B), yuv420p, 480x270 [SAR 1:1 DAR 16:9], 25 tbr, 90k tbn, 50 tbc
Metadata:
variant_bitrate : 388000
Stream #0:3: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, mono, s16
Metadata:
variant_bitrate : 388000
Stream #0:4: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 25 tbr, 90k tbn, 50 tbc
Metadata:
variant_bitrate : 713000
Stream #0:5: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, s16
Metadata:
variant_bitrate : 713000
Stream #0:6: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 960x540 [SAR 1:1 DAR 16:9], 25 tbr, 90k tbn, 50 tbc
Metadata:
variant_bitrate : 1412000
Stream #0:7: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, s16
Metadata:
variant_bitrate : 1412000
Stream #0:8: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 25 tbr, 90k tbn, 50 tbc
Metadata:
variant_bitrate : 2394000
Stream #0:9: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, s16
Metadata:
variant_bitrate : 2394000
Stream #0:10: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, mono, s16
Metadata:
variant_bitrate : 77000
File 'Moby_Dick_part1.mp4' already exists. Overwrite ? [y/N] y
Output #0, mp4, to 'Moby_Dick_part1.mp4':
Metadata:
encoder : Lavf54.6.100
Stream #0:0: Video: h264 (![0][0][0] / 0x0021), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 90k tbn, 90k tbc
Metadata:
variant_bitrate : 2394000
Stream #0:1: Audio: aac (@[0][0][0] / 0x0040), 48000 Hz, stereo
Metadata:
variant_bitrate : 713000
Stream mapping:
Stream #0:8 -> #0:0 (copy)
Stream #0:5 -> #0:1 (copy)
Press [q] to stop, [?] for help
No longer receiving variant 5ze= 2601kB time=00:00:10.32 bitrate=2065.0kbits/s
frame= 289 fps=8.8 q=-1.0 Lsize= 2991kB time=00:00:11.52 bitrate=2126.6kbits/s
video:2759kB audio:227kB global headers:0kB muxing overhead 0.174383%[/spoiler]
The same thing works fine runnning Libavs ffmpeg-command (but, strangly NOT running Libavs avconv, even though I thought it was basicly the same binay.
I uess Apple Http is still somewhat in the early stages of implementation in both projects?)
Might be the ffmpeg documentation is better than Libavs. I found several of the Libavs posted options to give an "unrecognzed variable" error with their ffmpeg-binary. They might have worked with avconv thought the documentaion did not mention it shouldn't work with the fmpeg one, just that you shouldn't use it. (But avconv, as mentioned, didn't work.)
Note that I had to use the -map option with libav because it was unable to choose the highest qualty stream, it just chose the firt ones. Fmmpegs ffmpeg handled this nicely, but always stops after 2759kB of video. My theory is that it fails to travrse the "playlist" file, so it ends up with no more chunks to encode. Note hat ffmpegs ffplay handle it without a hitch, so there does indeed seem to be bug somewhere here.
Various other commands were tired both usin Libav and ffmpeg to the same efffect: fmmpeg got the right stream for 2759kB, Libav never got the right stream unless specified, but got the whole file.
libav-git in AUR seems to be filling this niche just fine. I see no reason for Arch to move libav to community or extra, and the maintenance burden of providing two similar (but different) packages, and getting the dependencies to work with both, would probably be an unreasonable expectation. However, I am not an Arch maintainer, but I can imagine that it is a large undertaking for Ioni to deal with FFmpeg alone.
Yes, it's well and good hat it is in AUR, the problem is that replacing ffmpeg with libav breakes any video application using ffmpegs libvacodec, including vlc, Drgin etc., becuae these apllications in Arch repos are compiled for ffmpeg, not Libav.
But as I have read a bit about it and realized this, there is simply no way to make them coexist with each other and other dependencies. (Well, unless I could find a way to make them still use ffmpegs libav, which is a separate package). Still, I don't believe this is anything arch packagers could or should do anything with. Guess it is one or the other. I guess I'l file a ug report sometime in October when I have time. ![]()
Best: You could also use the bash script found on this page: http://nrkbeta.no/2012/04/23/test-nrks- … e-nett-tv/. Just search the page for "bash", and you will fid a comment form a user called gspr. Note tht that sript probaly have uite a few input-issues, don't run it on anything othr than nrk-URLS.
Also, DrZaius: The URL I posted is probably NOT available outside Norway. You could go to tv.nrk.no and find a program you can watch where you ar located (basicly most of NRKs own-produced content), and then use the curl part of the mentioned script to get a dirct link. Or you could try this: http://nordond3c-f.akamaihd.net/i/wo/op … u8#t=10,20
Sorry for all the typos, I have a replacement keyboard on the way. Someimes it writes out the key next to the key I push, and sometimes it just doesn't registrer the presses atall. Believe me, I have corrected more mistakes than the ones that are left, but they are still way too many...
Last edited by naguz (2012-08-04 22:31:18)
Offline
if is not working in ffmpeg, you should report to them as a bug or regression. is that simple.
Give what you have. To someone, it may be better than you dare to think.
Offline
Jepp, I will. Will build from git next weekend, and report a bug if it's a problem there as well.
Offline