Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

Seek problems with Handbrake 0.9.5 high profile encodings

  

 
MythTV users RSS feed   Index | Next | Previous | View Threaded


spuppet at comcast

Jan 25, 2012, 2:08 PM

Post #1 of 19 (557 views)
Permalink
Seek problems with Handbrake 0.9.5 high profile encodings
Hi all,

I'm having trouble with seeking in encodings of videos that have been created using Handbrake 0.9.5 and the "High Profile" preset. I don't have problems with recordings (HD-PVR and HDHR), ISOs, or other video files. This seems to have been discussed before on the list, but it doesn't look like it was completely resolved. The previous discussion is here: http://www.gossamer-threads.com/lists/mythtv/users/483209

On my system, seeking forward always seems to work fine, but seeking back will go back differing amounts. The amount it goes back seems to be somehow dependent on how long it's been since a seek back event occurred. That is, it's fairly accurate when I've seeked back recently (i.e. I seek back once, it takes me a long distance back in the recording, the next seek takes me back about the 5 seconds I expect). If no seek back has happened recently, when I seek back it can go 10 - 15 minutes back.

The old thread seems indicate that some people saw relief upgrading to 0.24, but since I'm already on that, I'm not sure where to look next. I don't recall this being a problem until relatively recently, but I don't know exactly when it started. Probably in the November/December timeframe. I've tried rebuilding the seek tables using mythcommflag, but that doesn't seem to have helped either.

I'm running 0.24.2/fixes on MythBuntu and keep up to date on updates. The frontend reports the following version:

Please attach all output as a file in bug reports.
MythTV Version : v0.24.2-3-ge4660d6
MythTV Branch : fixes/0.24
Network Protocol : 63
Library API : 0.24.20110505-1
QT Version : 4.6.2
Options compiled in:
linux profile using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_crystalhd using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg


Attached is the log output (playback.log.gz) from mythfrontend -v playback for a file demonstrating this problem. I started up the video, and after about 19 minutes, I hit the back button to go back 5 seconds. At the time that I did that, the current time on the OSD display said 15:00 minutes. After skipping back, the time said 14:57. (Not quite 5 seconds, but close.) The content, however, did skip back about 4 minutes of time to where the content should have been at 14:57 (verified with VLC). So, things got out of sync and even the OSD wasn't displaying the right time.

In the log file, I see many instances of messages like this:
2012-01-25 12:23:46.556 Player(0): Video is 3.14317 frames ahead of audio,
doubling video frame interval to slow down.

There's a slew of them when I do the skip back itself, in fact.

I also noticed that these messages popped up at the start of playback:

2012-01-25 12:23:35.579 VSYNC: DRMVideoSync: Could not open device /dev/dri/card0, No such file or directory
2012-01-25 12:23:35.579 VSYNC: RTCVideoSync: Could not open /dev/rtc, Permission denied.
2012-01-25 12:23:35.581 Player(0): Video timing method: USleep with busy wait
2012-01-25 12:23:35.581 Player(0): Display Refresh Rate: 60.002 Video Frame Rate: 29.971

Could this be a configuration problem? I know that I haven't messed with /dev/dri/card0 or /dev/rtc myself, but it's possible that something might have changed over time due to system updates. (Note, that chmod'ing /dev/rtc0 to 666 didn't seem to help it use that for timing.)

I also wasn't able to clearly see which audio stream that myth picked for playback. The video file has both an AC3 and an AAC stream.

The details for the video file are attached as videoinfo.txt.gz
Attachments: playback.log.gz (9.59 KB)
  videoinfo.txt.gz (1.31 KB)


spuppet at comcast

Jan 31, 2012, 9:59 AM

Post #2 of 19 (503 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On Jan 25, 2012, at 2:08 PM, Jason Gillis wrote:

> Hi all,
>
> I'm having trouble with seeking in encodings of videos that have been created using Handbrake 0.9.5 and the "High Profile" preset. I don't have problems with recordings (HD-PVR and HDHR), ISOs, or other video files. This seems to have been discussed before on the list, but it doesn't look like it was completely resolved. The previous discussion is here: http://www.gossamer-threads.com/lists/mythtv/users/483209
>
> On my system, seeking forward always seems to work fine, but seeking back will go back differing amounts. The amount it goes back seems to be somehow dependent on how long it's been since a seek back event occurred. That is, it's fairly accurate when I've seeked back recently (i.e. I seek back once, it takes me a long distance back in the recording, the next seek takes me back about the 5 seconds I expect). If no seek back has happened recently, when I seek back it can go 10 - 15 minutes back.
>
> The old thread seems indicate that some people saw relief upgrading to 0.24, but since I'm already on that, I'm not sure where to look next. I don't recall this being a problem until relatively recently, but I don't know exactly when it started. Probably in the November/December timeframe. I've tried rebuilding the seek tables using mythcommflag, but that doesn't seem to have helped either.

I've been experimenting with different encoding options in Handbrake to see what options change this behavior (and I'm finally seeing the real benefit of an i7! :). It seems like nothing I do for an .m4v file type seems to help. Choosing the normal or high profile doesn't seem to make much difference. (Normal might result in less drift from real time, though.)

I did find today that an MKV container instead of a .m4v results in no drift. I also don't see any messages in the -v playback logs about video getting ahead of the audio.

Is there anyone out there that could confirm this behavior, or perhaps confirm that there might be issues with processing of .m4v files? (I'm assuming ffmpeg handles that, so I'll do some searching about that.)

J


briandlong at gmail

Jan 31, 2012, 10:33 AM

Post #3 of 19 (510 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On Tue, Jan 31, 2012 at 12:59 PM, Jason Gillis <spuppet [at] comcast> wrote:

> I'm having trouble with seeking in encodings of videos that have been
> created using Handbrake 0.9.5 and the "High Profile" preset. I don't have
> problems with recordings (HD-PVR and HDHR), ISOs, or other video files.
> This seems to have been discussed before on the list, but it doesn't look
> like it was completely resolved. The previous discussion is here:
> http://www.gossamer-threads.com/lists/mythtv/users/483209
>
> On my system, seeking forward always seems to work fine, but seeking back
> will go back differing amounts. The amount it goes back seems to be
> somehow dependent on how long it's been since a seek back event occurred.
> That is, it's fairly accurate when I've seeked back recently (i.e. I seek
> back once, it takes me a long distance back in the recording, the next seek
> takes me back about the 5 seconds I expect). If no seek back has happened
> recently, when I seek back it can go 10 - 15 minutes back.
>
> The old thread seems indicate that some people saw relief upgrading to
> 0.24, but since I'm already on that, I'm not sure where to look next. I
> don't recall this being a problem until relatively recently, but I don't
> know exactly when it started. Probably in the November/December timeframe.
> I've tried rebuilding the seek tables using mythcommflag, but that doesn't
> seem to have helped either.
>
>
> I've been experimenting with different encoding options in Handbrake to
> see what options change this behavior (and I'm finally seeing the real
> benefit of an i7! :). It seems like nothing I do for an .m4v file type
> seems to help. Choosing the normal or high profile doesn't seem to make
> much difference. (Normal might result in less drift from real time,
> though.)
>
> I did find today that an MKV container instead of a .m4v results in no
> drift. I also don't see any messages in the -v playback logs about video
> getting ahead of the audio.
>
> Is there anyone out there that could confirm this behavior, or perhaps
> confirm that there might be issues with processing of .m4v files? (I'm
> assuming ffmpeg handles that, so I'll do some searching about that.)
>
> I recently encoded a few videos with Handbrake High profile and noticed
something similar, but I didn't attribute it to Handbrake. In fact, I've
not looked at the log or tracked it down. I was using a recent "nightly"
build of Handbrake x64 on Windoze 7.

/Brian/


spuppet at comcast

Jan 31, 2012, 11:18 AM

Post #4 of 19 (500 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
> I did find today that an MKV container instead of a .m4v results in no drift. I also don't see any messages in the -v playback logs about video getting ahead of the audio.
>
> Is there anyone out there that could confirm this behavior, or perhaps confirm that there might be issues with processing of .m4v files? (I'm assuming ffmpeg handles that, so I'll do some searching about that.)
>
> I recently encoded a few videos with Handbrake High profile and noticed something similar, but I didn't attribute it to Handbrake. In fact, I've not looked at the log or tracked it down. I was using a recent "nightly" build of Handbrake x64 on Windoze 7.


I just did another test and it does appear to be a Handbrake issue. I just dropped an m4v downloaded from iTunes into my system and it played flawlessly. No messages about video being ahead of audio and skipping back worked as expected. My assumption is that that video wasn't encoded using Handbrake.

I did some tests with a recent nightly build of Handbrake as well as the 0.9.5 official release and see the same behavior. Perhaps I'll have to find an alternative to Handbrake, or just switch to generating MKVs. At least with MKVs, I'd get better subtitle support…

J


jeremy.dwain.jones at gmail

Jan 31, 2012, 11:49 AM

Post #5 of 19 (502 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On Tue, Jan 31, 2012 at 11:59 AM, Jason Gillis <spuppet [at] comcast> wrote:
>
> On Jan 25, 2012, at 2:08 PM, Jason Gillis wrote:
>
> Hi all,
>
> I'm having trouble with seeking in encodings of videos that have been
> created using Handbrake 0.9.5 and the "High Profile" preset.  I don't have
> problems with recordings (HD-PVR and HDHR), ISOs, or other video files.
>  This seems to have been discussed before on the list, but it doesn't look
> like it was completely resolved.  The previous discussion is here:
>  http://www.gossamer-threads.com/lists/mythtv/users/483209
>
> On my system, seeking forward always seems to work fine, but seeking back
> will go back differing amounts.  The amount it goes back seems to be somehow
> dependent on how long it's been since a seek back event occurred.  That is,
> it's fairly accurate when I've seeked back recently (i.e. I seek back once,
> it takes me a long distance back in the recording, the next seek takes me
> back about the 5 seconds I expect).  If no seek back has happened recently,
> when I seek back it can go 10 - 15 minutes back.
>
> The old thread seems indicate that some people saw relief upgrading to 0.24,
> but since I'm already on that, I'm not sure where to look next.  I don't
> recall this being a problem until relatively recently, but I don't know
> exactly when it started.  Probably in the November/December timeframe.  I've
> tried rebuilding the seek tables using mythcommflag, but that doesn't seem
> to have helped either.
>
>
> I've been experimenting with different encoding options in Handbrake to see
> what options change this behavior (and I'm finally seeing the real benefit
> of an i7! :).  It seems like nothing I do for an .m4v file type seems to
> help.  Choosing the normal or high profile doesn't seem to make much
> difference.  (Normal might result in less drift from real time, though.)
>
> I did find today that an MKV container instead of a .m4v results in no
> drift.  I also don't see any messages in the -v playback logs about video
> getting ahead of the audio.
>
> Is there anyone out there that could confirm this behavior, or perhaps
> confirm that there might be issues with processing of .m4v files? (I'm
> assuming ffmpeg handles that, so I'll do some searching about that.)
>
> J
>

If this is a recording that was already in the database (recorded
using mythtv) then you need to re-build the seek tables after running
handbrake to transcode.

See:
http://www.mythtv.org/wiki/Repairing_the_Seektable

The line: mythcommflag --file <filepath> --rebuild
should do the trick.

If this is a new video file, just being dropped into mythvideos, then
I'm afraid my answer may be irrelevant, and I can't help.

Good luck,
Jeremy
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


spuppet at comcast

Jan 31, 2012, 12:36 PM

Post #6 of 19 (496 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On Jan 31, 2012, at 11:49 AM, Jeremy Jones wrote:
>
> If this is a recording that was already in the database (recorded
> using mythtv) then you need to re-build the seek tables after running
> handbrake to transcode.
>
> See:
> http://www.mythtv.org/wiki/Repairing_the_Seektable
>
> The line: mythcommflag --file <filepath> --rebuild
> should do the trick.
>
> If this is a new video file, just being dropped into mythvideos, then
> I'm afraid my answer may be irrelevant, and I can't help.
>
> Good luck,
> Jeremy


Rebuilding the seek tables had no effect: It just impacted on the surface. :(
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


spuppet at comcast

Jan 31, 2012, 12:40 PM

Post #7 of 19 (496 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
>> I did find today that an MKV container instead of a .m4v results in no drift. I also don't see any messages in the -v playback logs about video getting ahead of the audio.
>>
>> Is there anyone out there that could confirm this behavior, or perhaps confirm that there might be issues with processing of .m4v files? (I'm assuming ffmpeg handles that, so I'll do some searching about that.)
>>
>> I recently encoded a few videos with Handbrake High profile and noticed something similar, but I didn't attribute it to Handbrake. In fact, I've not looked at the log or tracked it down. I was using a recent "nightly" build of Handbrake x64 on Windoze 7.
>
>
> I just did another test and it does appear to be a Handbrake issue. I just dropped an m4v downloaded from iTunes into my system and it played flawlessly. No messages about video being ahead of audio and skipping back worked as expected. My assumption is that that video wasn't encoded using Handbrake.
>
> I did some tests with a recent nightly build of Handbrake as well as the 0.9.5 official release and see the same behavior. Perhaps I'll have to find an alternative to Handbrake, or just switch to generating MKVs. At least with MKVs, I'd get better subtitle support…
>

Another interesting thing I just saw: I re-encoded the file I've been testing using the "Universal" preset in Handbrake and noticed while watching the file that the time display in the current position bar in Myth's OSD was progressing at about half time. Each "second" it marked forward was taking about 2 seconds of real time. When I skipped back, it skipped back to the actual time position in the file (so if Myth said it was 10:00 in, but it was actually 20:00, it would skip back to the 10:00 mark).

What would cause Myth to not be able to correctly track the time in the file?

J


rjmorris at nc

Jan 31, 2012, 2:46 PM

Post #8 of 19 (487 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
Jason Gillis <spuppet [at] comcast> wrote on Tue, Jan 31, 2012 at 09:59:38AM -0800:
>
> I did find today that an MKV container instead of a .m4v results in
> no drift. I also don't see any messages in the -v playback logs about
> video getting ahead of the audio.
>
> Is there anyone out there that could confirm this behavior, or
> perhaps confirm that there might be issues with processing of .m4v
> files? (I'm assuming ffmpeg handles that, so I'll do some searching
> about that.)

I reported a similar issue recently. I had an mp4 that drifted like
you describe, but then I converted it to mkv and it was fine. I doubt
the mp4 was generated by handbrake, though.

http://www.gossamer-threads.com/lists/mythtv/users/499335
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


spuppet at comcast

Jan 31, 2012, 4:01 PM

Post #9 of 19 (487 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
>> I did find today that an MKV container instead of a .m4v results in
>> no drift. I also don't see any messages in the -v playback logs about
>> video getting ahead of the audio.
>>
>> Is there anyone out there that could confirm this behavior, or
>> perhaps confirm that there might be issues with processing of .m4v
>> files? (I'm assuming ffmpeg handles that, so I'll do some searching
>> about that.)
>
> I reported a similar issue recently. I had an mp4 that drifted like
> you describe, but then I converted it to mkv and it was fine. I doubt
> the mp4 was generated by handbrake, though.
>
> http://www.gossamer-threads.com/lists/mythtv/users/499335
>

Interesting. I like the tool that you used for that.

But, trying that out swung me back too far the other way. Now, the video gets behind what myth thinks is the current position, so seeking back actually skips me forward. It's not as far as before, though. There are a few messages in the -v playback logs about the video being behind the audio.

J
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mythtv at rtr

Jan 31, 2012, 4:14 PM

Post #10 of 19 (487 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On 12-01-31 05:46 PM, Joey Morris wrote:
> Jason Gillis <spuppet [at] comcast> wrote on Tue, Jan 31, 2012 at 09:59:38AM -0800:
>>
>> I did find today that an MKV container instead of a .m4v results in
>> no drift. I also don't see any messages in the -v playback logs about
>> video getting ahead of the audio.
>>
>> Is there anyone out there that could confirm this behavior, or
>> perhaps confirm that there might be issues with processing of .m4v
>> files? (I'm assuming ffmpeg handles that, so I'll do some searching
>> about that.)
>
> I reported a similar issue recently. I had an mp4 that drifted like
> you describe, but then I converted it to mkv and it was fine. I doubt
> the mp4 was generated by handbrake, though.


Late last fall, I noticed that many of my .mp4 files,
which previously played well under Mythtv (summer 2011),
now have stutter issues. This is 0.24-fixes, latest .git.

Re-packaging them as .mkv gets rid of the stutter.
So I've now done that for most of the .mp4 files in my archives.

Cheers
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


taylor.ralph at gmail

Jan 31, 2012, 4:21 PM

Post #11 of 19 (475 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On Tue, Jan 31, 2012 at 7:01 PM, Jason Gillis <spuppet [at] comcast> wrote:
>
>>> I did find today that an MKV container instead of a .m4v results in
>>> no drift.  I also don't see any messages in the -v playback logs about
>>> video getting ahead of the audio.
>>>
>>> Is there anyone out there that could confirm this behavior, or
>>> perhaps confirm that there might be issues with processing of .m4v
>>> files? (I'm assuming ffmpeg handles that, so I'll do some searching
>>> about that.)
>>
>> I reported a similar issue recently. I had an mp4 that drifted like
>> you describe, but then I converted it to mkv and it was fine. I doubt
>> the mp4 was generated by handbrake, though.
>>
>> http://www.gossamer-threads.com/lists/mythtv/users/499335
>>
>
> Interesting.  I like the tool that you used for that.
>
> But, trying that out swung me back too far the other way.  Now, the video gets behind what myth thinks is the current position, so seeking back actually skips me forward.  It's not as far as before, though.  There are a few messages in the -v playback logs about the video being behind the audio.
>

Could you provide the output of "mythffmpeg -i filename.ext" for both
the mp4 that doesn't play properly and the mkv that does? We may need
to handle mp4 as a special case. I'm assuming by the description of
the symptoms that we are using the wrong frame rate for the video.

Regards.
--
Taylor
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


spuppet at comcast

Jan 31, 2012, 4:37 PM

Post #12 of 19 (478 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
>>
>
> Could you provide the output of "mythffmpeg -i filename.ext" for both
> the mp4 that doesn't play properly and the mkv that does? We may need
> to handle mp4 as a special case. I'm assuming by the description of
> the symptoms that we are using the wrong frame rate for the video.
>
> Regards.


The m4v:
======================================

root [at] mini:/nas/video/Action# mythffmpeg -i Captain\ America.m4v > ~/m4v.txt
FFmpeg version UNKNOWN, Copyright (c) 2000-2010 the FFmpeg developers
built on Jan 24 2012 00:27:29 with gcc 4.4.3
configuration: --compile-type=profile --prefix=/usr --runprefix=/usr --enable-crystalhd --enable-lirc --enable-audio-alsa --enable-audio-oss --enable-dvb --enable-ivtv --enable-firewire --enable-joystick-menu --with-bindings=perl --enable-ffmpeg-pthreads --enable-pic --perl-config-opts='INSTALLDIRS=vendor' --enable-opengl-vsync --enable-opengl-video --cpu=i686 --enable-mmx --disable-xvmc --enable-vdpau
libavutil 50.24. 0 / 50.24. 0
libavcore 0. 6. 0 / 0. 6. 0
libavcodec 52.86. 1 / 52.86. 1
libavformat 52.78. 3 / 52.78. 3
libavdevice 52. 2. 1 / 52. 2. 1
libavfilter 1.37. 0 / 1.37. 0
libswscale 0.11. 0 / 0.11. 0
libpostproc 51. 2. 0 / 51. 2. 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x9e5c6b0] max_analyze_duration reached

Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 90000.00 (180000/2)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Captain America.m4v':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42isomavc1
encoder : HandBrake 0.9.5 2011010300
Duration: 02:04:10.07, start: 0.000000, bitrate: 1518 kb/s
Chapter #0.0: start -0.116789, end 491.157333
Metadata:
title : Chapter 1
Chapter #0.1: start 491.157333, end 895.895000
Metadata:
title : Chapter 2
Chapter #0.2: start 895.895000, end 1460.625833
Metadata:
title : Chapter 3
Chapter #0.3: start 1460.625833, end 1838.169667
Metadata:
title : Chapter 4
Chapter #0.4: start 1838.169667, end 2318.849867
Metadata:
title : Chapter 5
Chapter #0.5: start 2318.849867, end 2751.248500
Metadata:
title : Chapter 6
Chapter #0.6: start 2751.248500, end 3117.147367
Metadata:
title : Chapter 7
Chapter #0.7: start 3117.147367, end 3474.637833
Metadata:
title : Chapter 8
Chapter #0.8: start 3474.637833, end 3838.343756
Metadata:
title : Chapter 9
Chapter #0.9: start 3838.343756, end 4341.679922
Metadata:
title : Chapter 10
Chapter #0.10: start 4341.679922, end 4749.754256
Metadata:
title : Chapter 11
Chapter #0.11: start 4749.754256, end 5306.143422
Metadata:
title : Chapter 12
Chapter #0.12: start 5306.143422, end 5632.002289
Metadata:
title : Chapter 13
Chapter #0.13: start 5632.002289, end 6139.342456
Metadata:
title : Chapter 14
Chapter #0.14: start 6139.342456, end 6644.146756
Metadata:
title : Chapter 15
Chapter #0.15: start 6644.146756, end 6825.327756
Metadata:
title : Chapter 16
Chapter #0.16: start 6825.327756, end 7449.801600
Metadata:
title : Chapter 18
Stream #0.0(und): Video: h264, yuv420p, 720x368 [PAR 32:27 DAR 160:69], 735 kb/s, 23.97 fps, 90k tbr, 90k tbn, 180k tbc
Stream #0.1(eng): Audio: ac3, 48000 Hz, 2 channels, s16, 448 kb/s
Stream #0.2(eng): Audio: aac, 48000 Hz, stereo, s16, 328 kb/s
Stream #0.3(und): Subtitle: text / 0x74786574

The mkv (that plays well -- note that this is not the one I converted from the m4v using mkvmerge, it's a re-encode from the DVD source):
======================================

root [at] mini:/nas/video/tmp# mythffmpeg -i CA2.mkv
FFmpeg version UNKNOWN, Copyright (c) 2000-2010 the FFmpeg developers
built on Jan 24 2012 00:27:29 with gcc 4.4.3
configuration: --compile-type=profile --prefix=/usr --runprefix=/usr --enable-crystalhd --enable-lirc --enable-audio-alsa --enable-audio-oss --enable-dvb --enable-ivtv --enable-firewire --enable-joystick-menu --with-bindings=perl --enable-ffmpeg-pthreads --enable-pic --perl-config-opts='INSTALLDIRS=vendor' --enable-opengl-vsync --enable-opengl-video --cpu=i686 --enable-mmx --disable-xvmc --enable-vdpau
libavutil 50.24. 0 / 50.24. 0
libavcore 0. 6. 0 / 0. 6. 0
libavcodec 52.86. 1 / 52.86. 1
libavformat 52.78. 3 / 52.78. 3
libavdevice 52. 2. 1 / 52. 2. 1
libavfilter 1.37. 0 / 1.37. 0
libswscale 0.11. 0 / 0.11. 0
libpostproc 51. 2. 0 / 51. 2. 0
[matroska,webm @ 0x8fe46b0] max_analyze_duration reached
[matroska,webm @ 0x8fe46b0] Estimating duration from bitrate, this may be inaccurate

Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 59.94 (60000/1001)
Input #0, matroska,webm, from 'CA2.mkv':
Duration: 02:04:10.09, start: 0.000000, bitrate: 448 kb/s
Chapter #0.0: start 0.000000, end 491.157333
Metadata:
title : Chapter 1
Chapter #0.1: start 491.157333, end 895.895000
Metadata:
title : Chapter 2
Chapter #0.2: start 895.895000, end 1460.625833
Metadata:
title : Chapter 3
Chapter #0.3: start 1460.625833, end 1838.169667
Metadata:
title : Chapter 4
Chapter #0.4: start 1838.169667, end 2318.849867
Metadata:
title : Chapter 5
Chapter #0.5: start 2318.849867, end 2751.248500
Metadata:
title : Chapter 6
Chapter #0.6: start 2751.248500, end 3117.147367
Metadata:
title : Chapter 7
Chapter #0.7: start 3117.147367, end 3474.637833
Metadata:
title : Chapter 8
Chapter #0.8: start 3474.637833, end 3838.379678
Metadata:
title : Chapter 9
Chapter #0.9: start 3838.379678, end 4341.715844
Metadata:
title : Chapter 10
Chapter #0.10: start 4341.715844, end 4749.790178
Metadata:
title : Chapter 11
Chapter #0.11: start 4749.790178, end 5306.179344
Metadata:
title : Chapter 12
Chapter #0.12: start 5306.179344, end 5632.038211
Metadata:
title : Chapter 13
Chapter #0.13: start 5632.038211, end 6139.378378
Metadata:
title : Chapter 14
Chapter #0.14: start 6139.378378, end 6644.182678
Metadata:
title : Chapter 15
Chapter #0.15: start 6644.182678, end 6825.363678
Metadata:
title : Chapter 16
Chapter #0.16: start 6825.363678, end 7449.687367
Metadata:
title : Chapter 18
Chapter #0.17: start 7449.687367, end 7450.096000
Metadata:
title : Chapter 19
Stream #0.0(eng): Video: h264, yuv420p, 720x304, PAR 1:1 DAR 45:19, 23.98 fps, 59.94 tbr, 1k tbn, 180k tbc
Stream #0.1(eng): Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
Stream #0.2(eng): Audio: aac, 48000 Hz, stereo, s16
Stream #0.3(eng): Subtitle: dvdsub
Stream #0.4(eng): Subtitle: [0][0][0][0] / 0x0000

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


taylor.ralph at gmail

Jan 31, 2012, 6:28 PM

Post #13 of 19 (471 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On Tue, Jan 31, 2012 at 7:37 PM, Jason Gillis <spuppet [at] comcast> wrote:
>>>
>>
>> Could you provide the output of "mythffmpeg -i filename.ext" for both
>> the mp4 that doesn't play properly and the mkv that does? We may need
>> to handle mp4 as a special case. I'm assuming by the description of
>> the symptoms that we are using the wrong frame rate for the video.
>>
>> Regards.
>
>
> The m4v:
> ======================================
>
> root [at] mini:/nas/video/Action# mythffmpeg -i Captain\ America.m4v  > ~/m4v.txt
> FFmpeg version UNKNOWN, Copyright (c) 2000-2010 the FFmpeg developers
>  built on Jan 24 2012 00:27:29 with gcc 4.4.3
>  configuration: --compile-type=profile --prefix=/usr --runprefix=/usr --enable-crystalhd --enable-lirc --enable-audio-alsa --enable-audio-oss --enable-dvb --enable-ivtv --enable-firewire --enable-joystick-menu --with-bindings=perl --enable-ffmpeg-pthreads --enable-pic --perl-config-opts='INSTALLDIRS=vendor' --enable-opengl-vsync --enable-opengl-video --cpu=i686 --enable-mmx --disable-xvmc --enable-vdpau
>  libavutil     50.24. 0 / 50.24. 0
>  libavcore      0. 6. 0 /  0. 6. 0
>  libavcodec    52.86. 1 / 52.86. 1
>  libavformat   52.78. 3 / 52.78. 3
>  libavdevice   52. 2. 1 / 52. 2. 1
>  libavfilter    1.37. 0 /  1.37. 0
>  libswscale     0.11. 0 /  0.11. 0
>  libpostproc   51. 2. 0 / 51. 2. 0
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x9e5c6b0] max_analyze_duration reached
>
> Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 90000.00 (180000/2)
> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Captain America.m4v':
>  Metadata:
>    major_brand     : mp42
>    minor_version   : 0
>    compatible_brands: mp42isomavc1
>    encoder         : HandBrake 0.9.5 2011010300
>  Duration: 02:04:10.07, start: 0.000000, bitrate: 1518 kb/s
>    Chapter #0.0: start -0.116789, end 491.157333
>    Metadata:
>      title           : Chapter  1
>    Chapter #0.1: start 491.157333, end 895.895000
>    Metadata:
>      title           : Chapter  2
>    Chapter #0.2: start 895.895000, end 1460.625833
>    Metadata:
>      title           : Chapter  3
>    Chapter #0.3: start 1460.625833, end 1838.169667
>    Metadata:
>      title           : Chapter  4
>    Chapter #0.4: start 1838.169667, end 2318.849867
>    Metadata:
>      title           : Chapter  5
>    Chapter #0.5: start 2318.849867, end 2751.248500
>    Metadata:
>      title           : Chapter  6
>    Chapter #0.6: start 2751.248500, end 3117.147367
>    Metadata:
>      title           : Chapter  7
>    Chapter #0.7: start 3117.147367, end 3474.637833
>    Metadata:
>      title           : Chapter  8
>    Chapter #0.8: start 3474.637833, end 3838.343756
>    Metadata:
>      title           : Chapter  9
>    Chapter #0.9: start 3838.343756, end 4341.679922
>    Metadata:
>      title           : Chapter 10
>    Chapter #0.10: start 4341.679922, end 4749.754256
>    Metadata:
>      title           : Chapter 11
>    Chapter #0.11: start 4749.754256, end 5306.143422
>    Metadata:
>      title           : Chapter 12
>    Chapter #0.12: start 5306.143422, end 5632.002289
>    Metadata:
>      title           : Chapter 13
>    Chapter #0.13: start 5632.002289, end 6139.342456
>    Metadata:
>      title           : Chapter 14
>    Chapter #0.14: start 6139.342456, end 6644.146756
>    Metadata:
>      title           : Chapter 15
>    Chapter #0.15: start 6644.146756, end 6825.327756
>    Metadata:
>      title           : Chapter 16
>    Chapter #0.16: start 6825.327756, end 7449.801600
>    Metadata:
>      title           : Chapter 18
>    Stream #0.0(und): Video: h264, yuv420p, 720x368 [PAR 32:27 DAR 160:69], 735 kb/s, 23.97 fps, 90k tbr, 90k tbn, 180k tbc
>    Stream #0.1(eng): Audio: ac3, 48000 Hz, 2 channels, s16, 448 kb/s
>    Stream #0.2(eng): Audio: aac, 48000 Hz, stereo, s16, 328 kb/s
>    Stream #0.3(und): Subtitle: text / 0x74786574
>
> The mkv (that plays well -- note that this is not the one I converted from the m4v using mkvmerge, it's a re-encode from the DVD source):
> ======================================
>
> root [at] mini:/nas/video/tmp# mythffmpeg -i CA2.mkv
> FFmpeg version UNKNOWN, Copyright (c) 2000-2010 the FFmpeg developers
>  built on Jan 24 2012 00:27:29 with gcc 4.4.3
>  configuration: --compile-type=profile --prefix=/usr --runprefix=/usr --enable-crystalhd --enable-lirc --enable-audio-alsa --enable-audio-oss --enable-dvb --enable-ivtv --enable-firewire --enable-joystick-menu --with-bindings=perl --enable-ffmpeg-pthreads --enable-pic --perl-config-opts='INSTALLDIRS=vendor' --enable-opengl-vsync --enable-opengl-video --cpu=i686 --enable-mmx --disable-xvmc --enable-vdpau
>  libavutil     50.24. 0 / 50.24. 0
>  libavcore      0. 6. 0 /  0. 6. 0
>  libavcodec    52.86. 1 / 52.86. 1
>  libavformat   52.78. 3 / 52.78. 3
>  libavdevice   52. 2. 1 / 52. 2. 1
>  libavfilter    1.37. 0 /  1.37. 0
>  libswscale     0.11. 0 /  0.11. 0
>  libpostproc   51. 2. 0 / 51. 2. 0
> [matroska,webm @ 0x8fe46b0] max_analyze_duration reached
> [matroska,webm @ 0x8fe46b0] Estimating duration from bitrate, this may be inaccurate
>
> Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 59.94 (60000/1001)
> Input #0, matroska,webm, from 'CA2.mkv':
>  Duration: 02:04:10.09, start: 0.000000, bitrate: 448 kb/s
>    Chapter #0.0: start 0.000000, end 491.157333
>    Metadata:
>      title           : Chapter  1
>    Chapter #0.1: start 491.157333, end 895.895000
>    Metadata:
>      title           : Chapter  2
>    Chapter #0.2: start 895.895000, end 1460.625833
>    Metadata:
>      title           : Chapter  3
>    Chapter #0.3: start 1460.625833, end 1838.169667
>    Metadata:
>      title           : Chapter  4
>    Chapter #0.4: start 1838.169667, end 2318.849867
>    Metadata:
>      title           : Chapter  5
>    Chapter #0.5: start 2318.849867, end 2751.248500
>    Metadata:
>      title           : Chapter  6
>    Chapter #0.6: start 2751.248500, end 3117.147367
>    Metadata:
>      title           : Chapter  7
>    Chapter #0.7: start 3117.147367, end 3474.637833
>    Metadata:
>      title           : Chapter  8
>    Chapter #0.8: start 3474.637833, end 3838.379678
>    Metadata:
>      title           : Chapter  9
>    Chapter #0.9: start 3838.379678, end 4341.715844
>    Metadata:
>      title           : Chapter 10
>    Chapter #0.10: start 4341.715844, end 4749.790178
>    Metadata:
>      title           : Chapter 11
>    Chapter #0.11: start 4749.790178, end 5306.179344
>    Metadata:
>      title           : Chapter 12
>    Chapter #0.12: start 5306.179344, end 5632.038211
>    Metadata:
>      title           : Chapter 13
>    Chapter #0.13: start 5632.038211, end 6139.378378
>    Metadata:
>      title           : Chapter 14
>    Chapter #0.14: start 6139.378378, end 6644.182678
>    Metadata:
>      title           : Chapter 15
>    Chapter #0.15: start 6644.182678, end 6825.363678
>    Metadata:
>      title           : Chapter 16
>    Chapter #0.16: start 6825.363678, end 7449.687367
>    Metadata:
>      title           : Chapter 18
>    Chapter #0.17: start 7449.687367, end 7450.096000
>    Metadata:
>      title           : Chapter 19
>    Stream #0.0(eng): Video: h264, yuv420p, 720x304, PAR 1:1 DAR 45:19, 23.98 fps, 59.94 tbr, 1k tbn, 180k tbc
>    Stream #0.1(eng): Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
>    Stream #0.2(eng): Audio: aac, 48000 Hz, stereo, s16
>    Stream #0.3(eng): Subtitle: dvdsub
>    Stream #0.4(eng): Subtitle: [0][0][0][0] / 0x0000
>

Ok, could you create a ticket with the above info and also attach a
log file with "-v playback,timestamp,extra" for the video with
playback problems. That should be all I need to determine what is
going on.

Thanks.
--
Taylor
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


spuppet at comcast

Jan 31, 2012, 6:41 PM

Post #14 of 19 (467 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On Jan 31, 2012, at 6:28 PM, Taylor Ralph wrote:

> On Tue, Jan 31, 2012 at 7:37 PM, Jason Gillis <spuppet [at] comcast> wrote:
>>>>
>>>
>>> Could you provide the output of "mythffmpeg -i filename.ext" for both
>>> the mp4 that doesn't play properly and the mkv that does? We may need
>>> to handle mp4 as a special case. I'm assuming by the description of
>>> the symptoms that we are using the wrong frame rate for the video.
>>>
>>> Regards.
>>
>>
>> The m4v:
>> ======================================
>>
>>
>> The mkv (that plays well -- note that this is not the one I converted from the m4v using mkvmerge, it's a re-encode from the DVD source):
>> ======================================
>>
>>
>>
>
> Ok, could you create a ticket with the above info and also attach a
> log file with "-v playback,timestamp,extra" for the video with
> playback problems. That should be all I need to determine what is
> going on.
>
> Thanks.
> --
> Taylor

Will do later this evening or tomorrow. (WAF to look out for tonight… :)

Thanks for your help!

J

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


taylor.ralph at gmail

Feb 1, 2012, 8:00 AM

Post #15 of 19 (459 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On Tue, Jan 31, 2012 at 9:41 PM, Jason Gillis <spuppet [at] comcast> wrote:
>
>
> On Jan 31, 2012, at 6:28 PM, Taylor Ralph wrote:
>
>> On Tue, Jan 31, 2012 at 7:37 PM, Jason Gillis <spuppet [at] comcast> wrote:
>>>>>
>>>>
>>>> Could you provide the output of "mythffmpeg -i filename.ext" for both
>>>> the mp4 that doesn't play properly and the mkv that does? We may need
>>>> to handle mp4 as a special case. I'm assuming by the description of
>>>> the symptoms that we are using the wrong frame rate for the video.
>>>>
>>>> Regards.
>>>
>>>
>>> The m4v:
>>> ======================================
>>>
>>>
>>> The mkv (that plays well -- note that this is not the one I converted from the m4v using mkvmerge, it's a re-encode from the DVD source):
>>> ======================================
>>>
>>>
>>>
>>
>> Ok, could you create a ticket with the above info and also attach a
>> log file with "-v playback,timestamp,extra" for the video with
>> playback problems. That should be all I need to determine what is
>> going on.
>>
>> Thanks.
>> --
>> Taylor
>
> Will do later this evening or tomorrow.  (WAF to look out for tonight…  :)
>
> Thanks for your help!
>
> J
>

Thanks for opening the ticket. I don't see the playback log file
attached? You did provide the --version output.

Regards.
--
Taylor
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


spuppet at comcast

Feb 1, 2012, 8:20 AM

Post #16 of 19 (460 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
>> Thanks for opening the ticket. I don't see the playback log file
> attached? You did provide the --version output.

Trac had strong opinions about the size of my attachment (I hear that *all* the time from the ladies…), so I had to find an alternate way to provide it. :)

J
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


spuppet at comcast

Feb 4, 2012, 11:56 AM

Post #17 of 19 (423 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
> Thanks for opening the ticket. I don't see the playback log file
> attached? You did provide the --version output.
>
> Regards.
> --
> Taylor

Hi Taylor,

I saw that a change got committed last night. Thanks for taking this issue on and fixing it.

I'm using mythbuntu's repos, is there an easy way for me to test out this change? From the changes visible in git, it looks like they'll apply to the 0.24.2 sources, so I guess I can try building that and see how things fare, but I'm wondering if there's an easier way.

Jason

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


taylor.ralph at gmail

Feb 4, 2012, 12:04 PM

Post #18 of 19 (420 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
On Sat, Feb 4, 2012 at 2:56 PM, Jason Gillis <spuppet [at] comcast> wrote:
>> Thanks for opening the ticket. I don't see the playback log file
>> attached? You did provide the --version output.
>>
>> Regards.
>> --
>> Taylor
>
> Hi Taylor,
>
> I saw that a change got committed last night.  Thanks for taking this issue on and fixing it.
>
> I'm using mythbuntu's repos, is there an easy way for me to test out this change?  From the changes visible in git, it looks like they'll apply to the 0.24.2 sources, so I guess I can try building that and see how things fare, but I'm wondering if there's an easier way.
>

I don't know much about the mythbuntu repo, but as I understand you
can enable daily builds for the 0.24-fixes branch. So it should be in
the build that happens today.

Regards.
--
Taylor
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


spuppet at comcast

Feb 5, 2012, 9:33 AM

Post #19 of 19 (395 views)
Permalink
Re: Seek problems with Handbrake 0.9.5 high profile encodings [In reply to]
>
> I don't know much about the mythbuntu repo, but as I understand you
> can enable daily builds for the 0.24-fixes branch. So it should be in
> the build that happens today.
>

The fix showed up in an update last night. In some very limited testing, it seems to have resolved the problem. I'm not seeing any of the AV sync messages I was seeing before, and the seeking is working as expected.

I'll do some more testing, but I think that at this point, it's probably fixed.

Thanks for your help on this, Taylor!

J

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.